\documentclass{article}

%%%%%%%%%%%%%%%%%% Page Title Here
\newcommand{\TheTitle}{User Testing}
\input{header.tex}

\begin{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Actual Paper Here

\section*{UW Medical Center Demo}

\subsection*{Who:}

The people who we demoed our product to were staff from the UW Medical
Center. A majority of the people at the demo were people we didn't
know, and thus we didn't know their background. However, our client
Joseph, and the PhD student in charge of the routing algorithm,
Shabnam, were at the meeting as well. Overall, the background of this
group consisted of workers from the UW Medical Center.

\subsection*{Design:}

We asked our users, in this case the Medical Center group, to simply
watch us as we demoed the project to them. In our demo, we started off
by showing them the lab view of our website. We demonstrated that a
lab technician could see all packages that were arriving, in addition
to ETAs and expected amount of package arrivals for a given time.
They also were able to see how you could dynamically search for
packages and even check in items using the bar code scanner.

We then showed them the client view of our website. We showed how a
client site user could add new packages with items in them and that
they could view their currently shipped packages with their status.
The client site user could also dynamically search for packages they
shipped. Next we showed them how a client site adds a package and how
the lab user would then see it also in the lab view. Finally we showed
them our user manual which could be easily accessed from the top of
the web page.

Lastly, we demoed our Android application. We showed them the login
screen and the preferences that they could set. We also showed them
the beginning check list that every courier would see and the route
page which had a tab for routes and maps. We then showed them the
check lists per client site and how you could scan bar codes and mark
packages as collected. We finally showed them the ending check list a
courier would see after they finished their route for the day/shift.

\subsection*{What we learned:}

Product-wise, we learned that our product direction agreed with what
the direction laid out by the UW Medical group. However there were a
few features that the group believed to be important that we did
have. These include the ability:
\begin{itemize*}
\item for to the user to see who they are logged in as, essentially
  display their username somewhere, and a label for the client site
  they are at
\item to add any quantity of items by simply specifying an amount
\item to see what courier is associated to what package, at least on
  the lab view
\item to set different levels (such as read-only) within different
  user privilege levels
\item to print a log of what transpired in terms of packages based on
  a given time frame
\item to see timestamps on packages so that they can see when it was
  picked up and when it was delivered
\item to filter packages based on their timestamps
\end{itemize*}

We believe that many of these requested features are feasible before
the 1.0 release.

In terms of what we learned regarding user evaluation, we already
learned a lot from our user testing with people with no computer
experience. However, we found that, altogether it was really helpful
to have several users at once because the users could talk amongst
themselves about features and what they really want. Overall, we
learned a lot about properly demoing a product to a user and asking
for feedback.

\subsection*{What we are changing:}

Thanks to the good feedback we got from demo, we have started to
implement/change the features/issues that were raised during the
demo. For instance, the group member in charge of our website front
end has added a quantity box that allows user to specify the amount of
items to add. He is also working on displaying the current logged in
user and the client site they are associated to. Also, the
courier-package association is being added in. The logging and time
stamping we are currently discussing to see how these will be
implemented.

\section*{Non-CSE or Computer Related User Demos}

\subsection*{Who:}

The people who we demoed our product to were friends that have never
seen or heard of our product before. The background of the people that
used our product was relatively diverse. We have people who are
American Ethnic Studies majors and those who are undecided and not
planning to major in Computer Science. Overall, we tried our best to
find people who have no deep experience with computers or plans to
work with computers.

\subsection*{Design:}

Compared to our UW Medical group demo, the demos we did with these
users were much more free roaming in the sense they were allowed to
explore the product.

We asked our users first to use our Android application and login with
a predefined login.  We would explain each screen and its purpose, but
besides that, we tried not to interfere with the user and see if they
could figure out how to use our product with relative ease.  We also
answered any questions they had. After they became familiar with it,
we asked to perform the use case of scanning a package and marking it
as collected. Basically, we trained them to use our application and
then asked them to perform a task.

We did a similar approach with the lab view and allowed them to
explore and ask questions relating to what was displayed on the lab
view. We then asked them to pretend to be a lab technician and scan in
a bar code and look over the table and see if it had everything they
would want to know.

Finally we showed them the client site view. Since they had experience
already with the website, we simply asked them to add a package. We
guided them through the beginning process and explained what each
field was, but we did not interfere with the actual process of adding
a package and all its parts. We then told them to try to find their
package using the search bar.

\subsection*{What we learned:}

Product-wise, we learned that our product had a very good user
interface for the most part. Since the users didn't know much about
transporting specimens, they couldn't give us good feedback regarding
the transporting, checking in, etc. of the packages. However they did
give us feedback regarding general aspects such as:
\begin{itemize*}
\item fields should be more descriptive. Instead of saying
  description, we should say description of package/specimen/etc.
\item the graph for ETAs should be somewhere more visible such as on
  the side, and text boxes for adding packages shouldn't be so big
\item it would be nice to have a confirmation that a package was added
  successfully
\item the Android application needs to have a tutorial because real
  couriers don't have the luxury to explore unless we have a test
  account
\item our manuals need to look more appealing since it has no pictures
  or anything
\end{itemize*}

We believe that many of these requested features are implementable.

In terms of what we learned regarding user evaluation, we learned that
we should partition our testing better. We currently have a user test
all aspects of our product, but in general a user will usually only
have access to one aspect. We learned that even though we believed
that we had everything a user could possibly want that there was more
we could do. We also learned that user evaluations provide feedback
that is exactly what we needed to provide a product that the users
want.

\subsection*{What we are changing:}

Thanks to the good feedback we got from this demo, we have begun
considering the suggestions made by the users. Not all of the feedback
was good and necessary relevant, so we had to filter some of it
out. Beyond that, we have to pick out the important ones, and we also
have to consider the feedback that we got from the UW Medical group
since they're feedback is somewhat weighed more importantly. However,
easy stuff to do, such as formatting text boxes, will most likely be
done after we get the more desired features implemented.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%% End Paper Here
\end{document}